Organizations and businesses that develop, provide, or otherwise maintain cloud-based applications have become accustomed to relying on these services and implementing various types of environments from complex websites to applications and services provided as a software-as-service (SaaS) delivery model. Such services and applications are collectively referred to as “cloud applications.”
Cloud applications are typically accessed by users using a client device via a web browser. Cloud applications include, among others, e-commerce applications, social media applications, enterprise applications, gaming applications, media sharing applications, storage applications, software development applications, and so on. Many individual users, businesses, and enterprises turn to cloud applications in lieu of “traditional” software applications that are locally installed and managed. For example, an enterprise can use Office® 365 online services for email accounts, rather than having an Exchange® Server maintained by the enterprise.
The communication between a client device's browser and a server hosting a cloud application (or service) is typically established over a secured connection. A predominant communication protocol used to establish a secured connection is a secure sockets layer (SSL) protocol or a transport layer security (TLS) protocol. The SSL protocol utilizes cryptographic (SSL) certificates (or simply certificates) to establish the secured connection.
To establish a secured connection, the browser requests that the server identify itself. In response, the server sends a copy of its certificate including its public key. The browser then checks the certificate against a list of trusted certificate authorities (CAs). If the browser trusts the received certificate, the server creates, encrypts, and sends back a symmetric session key using the server's public key. The server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session over a secured connection. New certificates are created and signed only by certificate authorities (CAs).
In some cloud-computing deployments, the communication between client devices and cloud-applications is proxied by means of a proxy device. An example for such a deployment including a suffix proxy is illustrated in FIG. 1.
FIG. 1 shows an example network diagram 100 showing deployment including a suffix proxy. As seen in FIG. 1, a cloud computing platform 110 includes a server 117 executing one or more cloud applications 115. The cloud applications 115 are typically accessed by a user of a client device 130 via a web browser 131. The connection between the client device 130 and the server 113 is proxied by a suffix proxy 140. The suffix proxy 140 modifies any request to access one of the cloud applications 115, such that the request is directed to a different entity of the cloud computing platform.
To this end, the suffix proxy 140 typically inspects the network traffic to detect a request address (e.g., a URL) of one of the cloud applications 115. The suffix proxy 140 also modifies webpages, so that no network addresses are provided to the client device 130 that would direct the client device 130 to access the cloud application 115 directly. If such a network address is detected, the suffix proxy 140 rewrites that address, for example, by appending a predefined domain name to the original network address. The addition may refer or redirect the browser to a different proxy or server (not shown). For example, the URL (network address) https://www.oursite.com would be accessed through https://www.oursite.com.network-proxy-service.com.
To allow a secured communication between the browser 131 and a cloud application 115 addressed by the modified (suffixed) URL, the suffix proxy 140 serves a valid certificate that at least designates a domain name of the modified URL. Particularly, such a certificate must be signed by an authorized certificate authority (CA).
To this end, the suffix proxy 140 is typically pre-configured with a list of signed certificates, each of which designates (or signs) one or more signed domain names. A signed domain name is a domain name that is known to the proxy 140 a-priori (e.g., oursite.com.network-proxy-service.com). However, in most cases, the entity controlling the suffix proxy 140 is not the cloud service provider managing the cloud computing platform 110. Therefore, any configuration changes made in the platform 110 is not reported in the suffix proxy 140.
Specifically, the cloud service provider can add, remove, and/or modify applications, servers, and/or tenants from the cloud computing platform 110. For example, a cloud application previously addressed by https://www.oursite.com can support a new tenant (customer) at the address https://www.tenant1.oursite.com. The new address is suffixed as well by the proxy 140 (e.g., https://www.tenant1.oursite.com.network-proxy-service.com).
Such a change would require the suffix proxy 140 to maintain a certificate also signing the new suffixed address. If such a certificate is not maintained by the suffix proxy 140, then an error message (blocking access) is sent to the browser requesting to access an application addressed by the new suffixed address (https://www.tenant1.oursite.network-proxy-service.com).
One approach to overcome this limitation is by generating certificates on-demand by the suffix proxy 140. The generated certificate would sign the suffixed domain name as requested by the browser 131. To allow this, the proxy 140 must have its signing certificate installed on any client device 130 accessing the cloud platform 110. However, such a solution is not practical, and, regardless, is not a secured solution. For example, a proxy issuing its own certificates can be exploited to execute man-in-the-middle attacks.
It would therefore be advantageous to provide a solution that would overcome the deficiencies noted above.